\documentclass[a4paper,12pt]{article}
\usepackage[latin1]{inputenc}
\usepackage{graphicx}
\usepackage{listings}
\usepackage{fancyhdr}
\usepackage{multicol}
\usepackage{url}
\usepackage[font=small,labelfont=bf]{caption}
\usepackage[final]{pdfpages}
\linespread{1.3}


\title{Laboratory of Traffic Engineering}
\begin{document}
\maketitle

\section{Introduction}
This report illustrate the results obtained realizing some traffic engineering scenarios using OPNET modeler. 
The focus is on the IP and MPLS reliability and comparison of their recovery time.
First, we are going to the describe the used network, then we show the results collected by different scenarios.

\section{Network topology and infrastructure}
The network is composed by:
\begin{itemize}
\item eight \textbf{Juniper M10} routers
\item \textbf{100BaseT} duplex links 
\item two \textbf{Ethernet IP} workstation. One produce an amount of IP traffic, while the other only receives. The  departure time distribution depends on the scenario.
\end{itemize}
\begin{figure}[!htbp]
\centering
\includegraphics[width=\textwidth]{./figures/setup.pdf} 
\caption{Our network topology}
\label{fig:network topology}
\end{figure}
As one can see from \ref{network topology}, each workstation is connected to only one router, while the routers can have two or three active interfaces.
One thing that never changes in all the scenarios, is the packet size; in order to avoid packet fragmentation, which could mislead the results, we imposed an MTU of 1200 bytes that is less of the one used by ethernet (1500 bytes). 
The event in common to all our experimentation, is the fail of the link that connect \textit{node\_1} and \textit{node\_2}. The faults generation (and the eventual recovery of a link or a node) is possible in OPNET through the component Failure Recovery.

\section{Scenario 1: Dynamic IP routing using OSPF}
\graphicspath{{./figures/OSPF}}
In this scenario, called OSPF, the network level makes use of the routing protocol (in our case OSPF) to indirectly achieve recovery in case of failures. We can affirm that the recovery time collide with the convergence time of OSPF. 
We decided to use a constant departure time for the source, one hundred packets per second. This choice was made so that we can clearly see the packet loss in the result graph.

\begin{figure}[!htbp]
\centering
\includegraphics[width=\textwidth]{./figures/OSPF/OSPF_conv.pdf} 
\caption{ in red the convergence time of OSPF, in blue OSPF convergence activity,in green IP traffic received in the destination}
\label{fig:OSPF_link_failure }
\end{figure}

\subsection{Node failures in OSPF}

\begin{figure}[!htbp]
\centering
\includegraphics[width=\textwidth]{./figures/OSPF/OSPF_node_failure.pdf} 
\caption{ in red the convergence time of OSPF, in blue OSPF convergence activity,in green IP traffic received in the destination}
\label{fig: OSPF_node_failure }
\end{figure}
In fact, as it is shown in \ref{fig: OSPF results },  when the link fails, after 480 seconds, OSPF detect the link
 failure soon.  When a router receives the LSA Update message, with the infinity value for the failed link, it will recompute the new optimal path using the Dijkstra's algorithm. The convergence time of the network is the time that all the routers spends in order to find the best path. In this scenario, the convergence time is about 15 second, but it  also take some time to detect the failure (about one minute). We can see in \ref{fig: OSPF results } that some traffic is dropped due to the not  instantaneous failure detection. 
A thing that we could not explain was the double convergence activity at the start up of OSPF.

\section{ MPLS restoration using CSPF}

\section{ MPLS protection using Facility Backup}

\section{ MPLS with one to one Backup}

\section{ MPLS and static LSP}
\end{document}